@lovesegfault there is a second issue (duplicate for this). Is there a reason that this is still a draft?

#14172

Is there a reason that this is still a draft?

1. No repro and unclear how this can occur
2. It's AI slop and unclear if this fixes anything

Is there a reason that this is still a draft?

1. No repro and unclear how this can occur
2. It's AI slop and unclear if this fixes anything

@xokdvium can you tell me how much verbosity i need to activate, which does not output too much but still answers ericsons question in my ticket. I may be able to provide this once i reproduce it again (was not able to reproduce it locally but within a CI&CD)

Where you perhaps trying to build a specific output, and the derivation did not have an output with that exact name?

can you tell me how much verbosity i need to activate

debug would be ideal, but it's very noisy and contains curl logs that will leak potentially sensitive information. During the most recent call we've discussed some alternatives for providing more context to better debug this. #14194 might be helpful for this. I hope to finish that soon and backport it.

@xokdvium @lovesegfault this PR solves my problem, i cherry picked this change into 2.32.1 and the problem does not happen anymore. In addition I posted the code dump here: #14130 (comment)

@h0nIg see what i wrote on the issue. I am hesitant to do this except for as a last resort, it is as a real "shove the problem underneath the rug" fix.

We've started hitting this internally after I updated to 2.32, so I'm going to open this as it does seem to solve the problem.

Me and @xokdvium talked a bit about it today, and our best theory is that somehow there is a race to create the output, such as substitution vs building when only some outputs are cached, and then drv building races for that output.

@coderabbitai review

Walkthrough

In the DerivationGoal::haveDerivation function within derivation-goal.cc, the code now checks whether a wanted output is missing from the success.builtOutputs map. If missing, it injects an entry for that output using the current outputHash and includes a validity assertion with a debug message. This change replaces the previous assumption that the entry would always exist in the map, addressing cases where outputs were already valid and not re-registered.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

• Verify that the injected entry parameters (outputHash, validity assertion) are correctly computed and appropriate for the edge case
• Confirm the debug message accurately describes the scenario and aids in troubleshooting
• Validate that this graceful handling resolves the assertion failure without masking other issues
• Check that the fix applies to all relevant code paths where outputs may already be valid

Pre-merge checks and finishing touches

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

Backport failed for 2.31-maintenance, because it was unable to cherry-pick the commit(s).

Please cherry-pick the changes locally and resolve any conflicts.

git fetch origin 2.31-maintenance
git worktree add -d .worktree/backport-14137-to-2.31-maintenance origin/2.31-maintenance
cd .worktree/backport-14137-to-2.31-maintenance
git switch --create backport-14137-to-2.31-maintenance
git cherry-pick -x 9eecee3d4e28634ef11d0044bb2e84bd8b13f2c7

Successfully created backport PR for 2.32-maintenance:

• [Backport 2.32-maintenance] fix(libstore/build/derivation-goal): don't assert on partially valid outputs #14430